Ethan's Notes

Appearance

AI Agent 记忆系统 ​

1. 大白话：这是什么？解决什么痛点？ ​

  • 这是什么：Agent 的记忆系统，绝对不是把历史聊天记录一股脑全部塞给大模型，而是一套对信息进行筛选、压缩、提纯和更新的“智能代谢系统”。它通常分为两层：
    • 短期记忆（工作记忆）：跟着当前这一轮的会话（Session）走，用于暂存当前任务的中间状态（如 Intent、Observations），主要依赖大模型的上下文窗口（Context Window）。
    • 长期记忆：独立于会话之外的持久化“记事本”，用于跨会话记录用户的偏好、历史决策与过往经验，相当于 Agent 的跨会话个性化知识库。
  • 解决什么痛点：
    • “长任务失忆”与 Token 账单爆炸：大模型上下文窗口有限，无脑追加历史记录不仅容易撑爆窗口导致报错，更会导致 API Token 消耗飞涨。
    • “中间迷失”（Lost in the Middle）：模型在长上下文中更容易关注首尾，容易忽略夹在中间的关键信息。记忆系统通过提纯压缩，极大提高了上下文信噪比，防止模型跑偏。
    • “每次都要从零教起”：没有长期记忆持久化，一旦对话会话关闭，Agent 积累的用户画像和规范即消失。下次新对话时，用户还得重复教导模型自己的习惯。

2. 底层机制与高频考点 ​

  • 记忆的生命周期：编码 (Encode) → 存储 (Storage) → 提取 (Retrieval) → 巩固 (Consolidation) → 反思 (Reflection) → 遗忘 (Forgetting)。
    • 异步落库：在实际工程落地时，我们通常采用**“简单规则预筛 + 离线异步批处理”**（例如在后台异步提纯对话摘要写入实体库），以防止同步链路阻塞并保障稳定性。
    • 自省与反思：任务完成后，启动异步任务复盘成败，将教训提炼为元知识（Meta-Knowledge），合并碎片化的重复记忆，减少冗余。
    • 遗忘机制：基于时间衰减（如 $score = relevance \times importance \times decay(t)$ 指数衰减）和冲突解决（新事实覆盖并标记旧事实废弃）过滤陈旧噪声。
  • 高频面试对比考点：
    • 考点一：Agent 记忆 vs 历史聊天记录：记忆不是流水账，而是经过 LLM 异步提纯出来的结构化事实。必须配备过滤、去噪与遗忘治理，否则会导致“上下文腐化（Context Rot）”并给出过时建议。
    • 考点二：长期记忆 vs RAG（检索增强生成）：
      • RAG 挂载的是共享的世界知识库（如公司规章、产品文档），非个性化，主要防范越权召回。
      • 长期记忆 挂载的是高度个性化的偏好与历史决策（如特定技术栈、操作习惯），随用户演化，主要防范旧错固化。两者在 Prompt 中应严格分区注入。
    • 考点三：向量库记忆 vs Markdown 记忆：
      • 向量化记忆 (VectorStore)：适合海量非结构化文本的模糊语义检索（通常结合 BM25 混合检索）。
      • Markdown 轻量记忆（如 CLAUDE.md）：适合团队规范、项目习惯等小体量明文存储，优点是透明可审计、零运维成本、原生支持 Git 版本控制。
    • 考点四：短期记忆防膨胀策略：通常使用上下文缩减（滑动窗口裁剪或摘要压缩）、上下文卸载（大文件或大型工具返回结果用引用替代，按需异步读取）、上下文隔离（多 Agent 间只传任务指令而非广播全量历史）来控制。

3. 🎯 实战口径 ​

面试官提问：在你的项目中，你是如何设计并优化 Agent 记忆系统的？

口语化实战回答： “在我的苍穹外卖 AI 智能客服 Agent项目中，我设计了一套双轨制记忆系统（短期工作记忆 + 长期个性化记忆），并结合了语义缓存进行了深度优化，主要解决了大模型在长对话下的 Token 账单爆炸、中间迷失以及无法跨会话沉淀用户画像的问题。

首先，在长期记忆的构建上，为了避免同步阻塞影响首包时延，我采用了异步提纯落库的设计。当用户的对话会话结束后，系统会触发后台异步任务，调用大模型对本轮对话的短期记忆做语义过滤，提取出结构化事实（例如用户的菜品偏好、口味禁忌、常用地址等），持久化到数据库中。为了防止噪声和幻觉，我设置了置信度阈值，置信度低于 0.7 的事实直接丢弃。同时，提供 REST API 支持用户手动修正这些事实并保留审计历史。在检索阶段，系统在 Session 启动时，根据不同的意图类型，以三档粒度（全量 / 摘要 / 不注入）将用户记忆差异化注入 Prompt，实现了高度个性化的推荐，个性化推荐准确率得到了显著提升。

其次，在短期记忆和性能优化上，我引入了基于 JVM 内存的语义缓存。在 Spring AI Advisor 链的最前置，对用户的 FAQ 提问首先执行向量余弦相似度匹配。如果命中，直接从缓存中短路返回，绕过了 RAG 和大模型的耗时推理。当后台数据变更时，利用 Redis Pub/Sub 广播机制，异步重载各实例的本地缓存，保证了一致性。这套设计把高频 FAQ 的问答时延降到了毫秒级，同时极大保护了大模型的算力预算，降低了整体 Token 成本。”

相关链接：[[苍穹外卖AI客服]]